Other sections suggest that definitive objects are shown as Bold. Definitive objects don't really apply to the master (but maybe they should). Perhaps a better solution is to allow the punter to designate the criteria for instantiation as some sort of attribute. Can we really over-ride in the way it suggests below?
In an autonomous build all objects are created and managed by the application, thus there is one physical instance of each object. However, in a Master/Slave configuration objects are created and managed by the Master, which holds the physical instance of the objects. The Slave only holds the executable for the Active Objects, which it runs when instructed by the Master, and thus only holds virtual copies of the objects.
In some circumstances it is desirable for a Slave to create and manage its own objects. By changing the Objects Presence (Properties Window) from Root to Definitive, every node (Master and Slave) will create and manage their own physical instance of that object.
Since these objects all exist, where they connect to a non-definitive (Root) object they will compete for any events.
If the events are intended to be sent to all definitive objects then they should be distributed (via a non-definitive distributer).
In practice making one object definitive is restrictive. Usually several objects or more commonly a circuit (including all of its child objects, which inherit the definitive flag) are made definitive.
Why would you do this? that's best answered with a couple of examples
- Remote GUI - each node creates its own GUI (dialogs, callbacks) with independent dialogs and displays - see NetComm - audio control
- Remote Processing - each node creates its own copy of some part of the processing (stores, methods) - see NetComm - audio mixing
- Remote Sensors - each node has its own input sensors (devices, threads), which it reads and sends to the master - see NetComm - microphone input
In this way the number of remote displays/sensors etc. can be increased/decreased without any modifications to the code. In fact the number of remote nodes is purely a run-time issue, with nodes being added and removed during execution.
In many applications of this type, there is a central (non-definitive) Ast holding the common system control parameters, which all remote nodes can access to keep in sync, and any new nodes can pick up the state of the system and initialise accordingly.
Selective Definitive
By overloading the Create() functions where the various flags are passed to CLIP it's possible selectively change the flags.
Uns MyCircuit_ThrdInst1Thrd::Create()
{
// create this Thrd as definitive on slaves
// but dont create it on the master
Uns failed = FALSE;
if ( ClpAmSlave() )
{
Uns dims[] = {1};
Uns objFlags = CLP_MEM_DEFAULT | CLP_MEM_TEMP;
objFlags |= CLP_DEFINITIVE; // was CLP_ROOT
failed |= ! ClpThrd<MyCircuit_ThrdInst1ThrdElem>::Create(
"ThrdInst1",
1,
1,
0,
0x10000,
objFlags,
DefaultSeg(),
1,
dims );
}
return ! failed;
}